COMMENT ⊗   VALID 00006 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	Dialnet memo #3
C00004 00003			       CONVENTIONS USED IN THIS DOCUMENT
C00006 00004					    PREFACE
C00009 00005			     ESTABLISHING AND BREAKING A CONNECTION
C00015 00006					ACKNOWLEDGEMENTS
C00016 ENDMK
C⊗;
Dialnet memo #3
SAILON by

















			       Dialnet Protocols

			  (or, the Protocols of DIAL)

			  Initial Connection Protocol

				  Mark Crispin

				    12/26/77

























     These protocols are being developed as  part of the Dialnet project at  the
Stanford University Artificial  Intelligence Laboratory supported  by NSF  grant
MCS 77-02080  with John  McCarthy  as Principal  Investigator.  The  project  is
described  in   a   paper   available   online  at   ARPAnet   host   SU-AI   as
DIALNE.MEM[DLN,MRC] (Dialnet Memo #1).

     This is ICP.PRO[DLN,MRC] at ARPAnet host SU-AI (octal 13, decimal 11.).
		       CONVENTIONS USED IN THIS DOCUMENT

     All numbers  without an  explicit  base (ie,  octal or  decimal)  specified
should be interpreted as  octal unless the number  is immediately followed by  a
dot, in which  case it  is decimal.   However, numbers  with intervening  spaces
every three digits should be treated as binary (the intervening spaces are  used
to facilitate conversion to octal).

     All three-digit  octal numbers  should be  interpreted as  representing  an
8.-bit byte, with bits right-justified within the number (ie, from 000 to  377).
Bytes are expressed in the  form as returned by the  modem (ie, lsb first);  ie,
105 is transmitted in the bit stream as 101 000 10.

     All six-digit octal numbers should be interpreted as representing a 16.-bit
double-byte, with bits  right-justified within  the number (ie,  from 000000  to
177777).  Double-bytes are expressed in the form returned by the modem (ie,  low
order byte and lsb first); ie, 010041 is transmitted as 100 001 000 000 100 0.

     It is assumed that the reader is familiar with the contents of Dialnet memo
#2, Dialnet Host-Host Protocols.
				    PREFACE

       "Aren't you glad you use Dialnet?  Don't you wish everybody did?"


     This document specifies a  protocol for use  in communication between  Host
computers  using  the  Dialnet  protocols.   In  particular,  it  provides   for
connection of independent processes in different  hosts, control of the flow  of
data of established connections, and other related functions.

     Although self-contained, this  document specifies only  one of the  Dialnet
protocols.  In particular, this document only specifies how a connection between
processes on two different hosts is to be established.

     Questions concerning Dialnet protocols should be addressed to:

				  Mark Crispin
		  Stanford Artificial Intelligence Laboratory
			  Stanford, California  94305
				 (415) 491-1407
				   MRC@SU-AI

     Copies of  all  Dialnet-related  correspondence  should  be  sent  to  John
McCarthy (Dialnet principal investigator) and Les  Earnest at the above US  mail
address or via ARPAnet mail to JMC@SU-AI and LES@SU-AI.

     It is the  intent of the  author that  these protocols are  both simple  in
their implementation and powerful in their operation.  Certainly a major  design
consideration was to design protocols  that ordinary mortals could implement  on
their systems.

     The intended audience of  Dialnet ranges from fairly  small to quite  large
systems, however,  Dialnet  has  been  designed to  be  nice  for  medium  sized
time-sharing systems, such as PDP-10's and DECsystem-20's.
		     ESTABLISHING AND BREAKING A CONNECTION

     This is  the  basic mechanism  in  establishing a  connection  between  two
tertiary processes in a duplex connection.  In the discussion below, U refers to
the process which initially provokes the connection or USER, S refers to the the
process passively waiting for a connection or SERVER.

     If a dialup connection has just  been established, both hosts should  start
with packet number 000.   They should then  proceed to send  RSTs at each  other
until both  have  received  acknowledgements  for their  RSTs.   After  this,  a
physical connection has been established and  a process connection may be  made.
It should be noted  that until the physical  connection has been established  no
other packets (including  ERR!!) should be  sent.  Bad data  received should  be
ignored until the RST/ACK  synchronization has occured.  Should  synchronization
fail to occur within 120. seconds, the hosts may hang up.

     Following the receipt of an ACK for its RST, each host should start sending
(and  acknowledging)  NOP's  at  each   other  until  both  have  received   and
acknowledged the other's NOP.  This prevents problems with extra RST's still  in
transit.

     U must know the  process ID of  the S it  wants to connect  to.  As far  as
Dialnet is  concerned,  process  ID's are  arbitrary  ASCII  strings.   However,
conventions have been established as noted elsewhere.

     U instructs its DCP  to send an RPC  with the process ID  at S it wants  to
connect to.

     The DCP  at S's  host passes  the  request along  to S.   S may  have  been
listening for a connection, or perhaps was created by the DCP as a result of the
RPC.  If no such process exists or the DCP is unable to create the process,  the
DCP should refuse the connection by sending back a CLS.

     S then decides whether or not it wants to talk to U.  If not, it  instructs
the DCP  to refuse  the connection.   Otherwise, it  accepts the  connection  by
instructing its DCP  to send an  RPC back to  U's DCP, with  a zero process  ID.
This RPC is sent as if S were trying to initiate a connection with U instead  of
the other way around.

     Once a connection has been established, the process ID is no longer used by
the host-host protocol.

     The two hosts may then  pass data back and  forth between each other  using
the MSG op-code.  When a host wishes to terminate a connection, it sends a CLS.

     Once a CLS has been sent, no further MSG's may be sent and any MSG sent  is
to be replied to with  an ERR.  Of course, a  new connection may be  established
with RPC.

     When a connection is terminated, the recepient  of the CLS must send a  CLS
to confirm terminating  the process.   This avoids timing  errors and  confusion
that could occur if both ends want to close at about the same time and both send
almost simultaneous CLS's.  The result is that a received CLS is interpreted  as
a confirmation despite whether  it really was or  wasn't spontaneous; in  either
case no confirmation is needed.

     Breaking the phone connection implies a RST which in turn implies  breaking
the process connection.
				ACKNOWLEDGEMENTS

     Les Earnest  (SAIL), John  McCarthy (SAIL),  Dave Moon  (MIT), and  Richard
Stallman (MIT)  provided invaluable  encouragement and  assistance in  designing
(and debugging) this protocol and in proofreading this document.

     I take sole responsibility for whatever is inaccurate or unclear.